Present-day communication systems are usually based on what is known as the OSI layer model (Open System Interconnection layer model), which shares different communication tasks between computers on different communication layers.
The hierarchically structured OSI layer model includes what is known as the application layer, on which customary application protocols, such as for example for communication between electronic mail programs, Internet browser programs or else other application programs, are executed.
Arranged hierarchically under it are what are known as network layers, which are responsible for transparent communication between computers communicating with one another and possibly switching processors lying in between in a communication link. Examples of network layers are layers which provide a communication between computers according to the Internet Protocol (IP) or according to the Transport Control Protocol (TCP) or else according to the User Datagram Protocol (UDP).
Known application protocols of layer 7, using the Internet Protocol (IP) on OSI layer 3, provide not only their core functionality but usually also a more or less extensive set of security mechanisms for the protection of the communication conducted by the application protocol (protocol on the level of the application layer in the OSI layer model). Among the security objectives to be achieved in this process, the authentication of the messages according to the application protocol and also their integrity and confidentiality are of very great importance.
Until now, two possibilities have been known for achieving these security objectives. On the one hand, the application protocol itself may be protected, that is to say a cryptographic protection may take place on the level of the application layer. Since such an application protocol on the basis of IP runs above the network layer, considered hierarchically, reference is also made in this case to an assured security on the level of the application layer. For this purpose, modifications of the application protocol itself are usually required, or the security mechanisms are already contained in the specification of the respective application protocol.
On the other hand, it is known to protect the application protocols in one of the network layers lying under the application layer, for example according to the IP or the TCP. As a solution for security on the level of the network layer, in other words on the network level, the architectures according to IPsec (see, “Understanding the IPsec Protocol Suite, Secure Virtual Private Network Solutions,” Timestep Corporation, December 1998) or TLS (Transport Layer Security) are known.
IPsec represents an expansion of the Internet Protocol (IP) communication protocol of OSI layer 3, by which security services are provided on the level of the network layer. According to the IPsec protocol, cryptographic protection is provided in a transparent way for every type of application which uses the protocol according to IPsec of the network layer for communication on the level of the application layer.
As described in “Understanding the IPsec Protocol Suite, Secure Virtual Private Network Solutions,” the Encapsulating Security Payload protocol (ESP) is used for IPsec to protect the user data transmitted, in particular for authentication and for encryption, and the Authentication Header (AH) protocol is used for pure authentication of the communication partners.
Within the security protocol IPsec, what are known as security associations (SA) are used between the computers communicating with one another. Such a security association is to be understood hereafter as meaning a set of security parameters for a communication link to be set up later, which include in addition to the key material to be used for a cryptographic method further parameters and security policy information, such as for example the cryptographic algorithms to be used, a maximum service life of keys or a maximum service life of the security association itself, or else identification data for identifying the communication partners.
Furthermore, the security association may also include in particular the cryptographic parameters defined in IETF RFC 2407: IP Security Domain of Interpretation, a selection of which is presented below. The security association may, for example, include:                a security parameter index, with which the security association between two entities communicating with one another, preferably computers communicating with one another, is unequivocally identified in each case,        a security association life type, with which the unit in which the service life of the security association is measured, optionally seconds or kilobytes, is indicated,        a security association lifetime, in other words the indication of a point in time or a time duration until which or during which the indicated security association is valid for a communication between the two associated entities, and consequently the indicated security parameters can be used for a communication,        an indication of an encryption algorithm to be used in a later communication link using this security association, which algorithm is used according to the ESP,        an indication of an authentication algorithm to be used within a later communication link,        an indication of the key length,        an indication of possibly existing key rings to be used.        
Protocols for negotiating security associations are described in IETF RFC 2409: The Internet Key Exchange (IKE) and Internet Engineering Task Force: Draft-IETF-KINK-KINK-00.txt. These independent protocols, which run independently of an application protocol, are very complex and computationally intensive and are consequently not suitable for implementation in a communication device having only a low computing capacity, in particular in a mobile communication terminal. Furthermore, according to the methods described in IETF RFC 2409 and Draft-IETF-KINK-KINK-00.txt, an independent communication is required for negotiating the security associations. To illustrate the disadvantages described above of the methods described in IETF RFC 2409 and Draft-IETF-KINK-KINK-00.txt, these methods are briefly outlined in the text which follows.
The protocol according to IETF RFC 2409 has two phases. In a first phase, what is known as an IKE security association, in other words a cryptographically protected communication channel, is produced between two computers communicating with one another. On the basis of the IKE security association, a second phase can be subsequently executed, during which the actual IPsec security associations are generated. According to IETF RFC 2409, use of what is known as the “Diffie-Hellman Key Exchange” protocol, which necessitates complex asymmetrical cryptographic computations in the computers, is required in the first phase.
In particular, the current capability of processor units in mobile communication terminals, such as mobile radio telephones, stands in the way of efficient use of this method. It should further be noted that the IKE protocol is based on the comprehensive ISAKMP standard. Altogether, the implementation of IKE is very complex and prone to errors, making the protocol only very poorly suited for communication terminals with only low computing capacity.
The protocol described in Draft-IETF-KINK-KINK-00.txt, referred to as the KINK protocol, prescribes the use of what is known as the Kerberos standard. This is likewise very extensive and complex and rather inefficient in its implementation on a mobile communication terminal with low computing capacity.
Furthermore, what is known as the Session Initiation Protocol (SIP), as described in IETF RFC 2543: Session Initiation Protocol, is an example of an application protocol. The SIP is a protocol which is defined on the level of the application layer and specifies the signaling for controlling communication sessions. Communication sessions controlled by SIP are, for example, telephone conversations or multimedia conferences over the Internet. The SIP uses either “request” messages from a client to a server, or “response” messages from a server to the client.
A further protocol on the application layer is the Hypertext Transfer Protocol (HTTP).
In Ericsson, Nokia and Nortel, “Security Mode Setup for the IMS Registration,” 3GPP TSG SA WG 3 Security-S3##19, S3-010326, Jul. 4-6, 2001, it is described for a future UMTS protocol that SIP is used between a mobile communication terminal and a mobile radio network computer for negotiating which algorithm is to be used for protecting integrity. This procedure is only very poorly suited for practical implementation, since the restriction to the negotiation of an algorithm which is to be used in a future communication link for protecting integrity is not adequate to satisfy present-day requirements within the scope of mobile multimedia communication.